Virtual regulator for multi-databases systems

ABSTRACT

A system for managing a plurality of systems, includes a domain comprised of a plurality of systems, wherein the systems are managed by one or more closed-loop system management (CLSM) regulators. A virtual regulator manages operational characteristics of the domain and the plurality of systems, by communicating with the CLSM regulators to monitor the systems&#39; states, events and conditions within the domain and to adjust the systems&#39; operational characteristics in response to the systems&#39; states, events and conditions.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. § 119(e) to thefollowing co-pending and commonly assigned applications:

U.S. Provisional Patent Application Ser. No. 60/877,767, filed on Dec.29, 2006, by Douglas P. Brown, Anita Richards, John Mark Morris and ToddA. Walter, and entitled Virtual Regulator for Multi-Database Systems,attorneys' docket no. 12787;

U.S. Provisional Patent Application Ser. No. 60/877,766, filed on Dec.29, 2006, by Douglas P. Brown, Scott Gnau and John Mark Morris, andentitled Parallel Virtual Optimization, attorneys' docket no. 12841;

U.S. Provisional Patent Application Ser. No. 60/877,768, filed on Dec.29, 2006, by John Mark Morris, Anita Richards and Douglas P. Brown, andentitled Workload Priority Influenced Data Temperature, attorneys'docket no. 12788; and

U.S. Provisional Patent Application Ser. No. 60/877,823, filed on Dec.29, 2006, by John Mark Morris, Anita Richards and Douglas P. Brown, andentitled Automated Block Size Management for Database Objections,attorneys' docket no. 12789;

all of which applications are incorporated by reference herein.

This application is related to the following co-pending and commonlyassigned applications:

United States Utility patent application Ser. No. 10/730,348, filed Dec.8, 2003, by Douglas P. Brown, Anita Richards, Bhashyam Ramesh, CarolineM. Ballinger and Richard D. Glick, and entitled Administering theWorkload of a Database System Using Feedback, attorney's docket no.11167;

United States Utility patent application Ser. No. 10/786,448, filed Feb.25, 2004, by Douglas P. Brown, Bhashyam Ramesh and Anita Richards, andentitled Guiding the Development of Workload Group DefinitionClassifications, attorneys' docket no. 11569;

United States Utility patent application Ser. No. 10/889,796, filed Jul.13, 2004, by Douglas P. Brown, Anita Richards, and Bhashyam Ramesh, andentitled Administering Workload Groups, attorneys' docket no. 11560;

United States Utility patent application Ser. No. 10/915,609, filed Aug.10, 2004, by Douglas P. Brown, Anita Richards, and Bhashyam Ramesh, andentitled Regulating the Workload of a Database System, attorneys' docketno. 11561;

United States Utility patent application Ser. No. 11/468,107, filed Aug.29, 2006, by Douglas P. Brown and Anita Richards, and entitled A Systemand Method for Managing a Plurality of Database Systems, attorneys'docket no. 12162, which applications claims the benefit of U.S.Provisional Patent Application Ser. No. 60/715,815, filed Sep. 9, 2005,by Douglas P. Brown and Anita Richards, and entitled A System and Methodfor Managing a Plurality of Database Systems, attorneys' docket no.12162;

United States Utility patent application Ser. No. ______, filed on samedate herewith, by Douglas P. Brown, Scott Gnau and John Mark Morris, andentitled Parallel Virtual Optimization, attorneys' docket no. 12841;

United States Utility patent application Ser. No. ______, filed on samedate herewith, by John Mark Morris, Anita Richards and Douglas P. Brown,and entitled Workload Priority Influenced Data Temperature, attorneys'docket no. 12788; and

United States Utility patent application Ser. No. ______, filed on samedate herewith, by John Mark Morris, Anita Richards and Douglas P. Brown,and entitled Automated Block Size Management for Database Objections,attorneys' docket no. 12789;

all of which applications are incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a system and method for managing aplurality of database systems.

2. Description of Related Art

As database management systems (DBMS) continue to increase in functionand expand into new application areas, the diversity of databaseworkloads is increasing as well. In addition to the classic relationalDBMS workload consisting of short transactions running concurrently withlong decision support queries, workloads comprising of an even widerrange of system demands are emerging. New complex data types, such asimage files, audio files, video files and other large objects, and newactive data warehouse requirements, such as capacity on demand, datareplication, fault-tolerance, dual active query processing, recursion,user defined types (UDFs), external UDFs, and so on, result in widelyvarying memory, processor, disk and network demands on database systems.

In general, a DBMS has a number of operational characteristics. Theseinclude physical statistics, such as CPU usage, query response times andperformance statistics. In some DBMS, the operational characteristicsinclude rule sets under which the database operates, relating to thelikes of resource consumption and request prioritization. Varying theserule sets often has an effect on other physical characteristics, forexample altering performance statistics. Ideally, a DBMS should be ableto accept performance goals for a workload and dynamically adjust itsown performance based on whether or not these goals are being met.

Closed-loop system management (CLSM) is a technology directed towardsthis ideal. Under some known CLSM-type systems, incoming queries aresplit into workload groups, each workload group having respectiveservice level goals (SLGs). The DBMS is responsive to whether or notthese goals are met for selectively switching between predetermined rulesets or adjusting performance controls.

It is also known to operate multi-system environments, wherein aplurality of databases, database systems, or DBMS operate in parallel.For example, DBMS that use a Massively Parallel Processing (MPP)architecture across multiple systems or a Symmetric Multiprocessing(SMP) architecture. In particular, it is known to operate a“dual-active” system wherein a plurality of databases operate inparallel and intercommunicate. It will be appreciated that managingcomplex workloads and performance objectives across the board in amulti-system environment is difficult.

Consequently, there is still a need in the art for additional managementtechniques for use in multi-system environments. The present inventionsatisfies this need.

SUMMARY OF THE INVENTION

To overcome the limitations in the prior art described above, and toovercome other limitations that will become apparent upon reading andunderstanding the present specification, the present invention disclosesa system for managing a plurality of systems, includes a domaincomprised of a plurality of systems, wherein the systems are managed byone or more CLSM regulators. A virtual regulator manages operationalcharacteristics of the domain and the plurality of systems, bycommunicating with the CLSM regulators to monitor the systems' states,events and conditions within the domain and to adjust the systems'operational characteristics in response to the systems' states, eventsand conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representcorresponding parts throughout:

FIG. 1 is a block diagram that illustrates the operation of a CLSMregulator according to the preferred embodiment of the presentinvention.

FIGS. 2, 3, 4 and 5 are block diagrams that illustrate the operation ofa virtual regulator according to the preferred embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following description of the preferred embodiment, reference ismade to the accompanying drawings which form a part hereof, and in whichis shown by way of illustration a specific embodiment in which theinvention may be practiced. It is to be understood that otherembodiments may be utilized and structural changes may be made withoutdeparting from the scope of the present invention.

Overview

The present invention discloses a Virtual Regulator that uses DBMS andCLSM technologies to manage workloads in a multi-system environment.Specifically, the Virtual Regulator has the capability to manageworkloads across a domain comprised of multiple systems managed by oneor more CLSM regulators in order to achieve a set of SLGs.

System Description

Referring initially to FIG. 1, there is provided a CLSM Regulator 10 formanaging a plurality of database systems 12 and 14. The CLSM Regulator10 includes an interface 16 for obtaining data 18 indicative of one ormore operational characteristics of each of database system 12 and 14. Amonitor 20 analyzes the data 18 and provides a signal 22 indicative ofan instruction to adjust one or more of the operational characteristicsof a selected one of database systems 12 and 14.

In the present disclosure, the term “database systems” is used in ageneral sense, and is meant to include the wider range of componentsused in conjunction with a database in a database system. In someembodiments, database systems 12 and 14 are simple tables of data,whereas in other embodiments they include complex relational databasemanagement systems (RDBMS). An example of such a database system 12 or14 is the Teradata® RDBMS sold by NCR Corporation, the assignee of thepresent invention.

At a high level, the CLSM Regulator 10 operates as a controllerincluding a feedback response mechanism for a domain defined by aplurality of database systems 12 and 14. It is responsive to theperformance of the domain insofar as database requests 24 are performedwithin predefined threshold requirements. The CLSM Regulator 10 isresponsive to data 18 indicative of this performance for adjustingsettings, such as resource consumption rules and query prioritizationsettings, in the database systems 12 and 14. In many embodiments, thisis used to better ensure that the available resources are utilized in amanner conducive to efficiently processing a variable workload.

It will be appreciated that the terms “workload class” (WC), “workloadgroup” (WG) and “workload definition” (WD) are substantially synonymous.That is, the terms each relate to the same general identificationstructure used to separate requests for prioritization, processing andperformance monitoring in a database system 12 or 14 including a CLSMRegulator 10.

In the present example, the CLSM Regulator 10 analyzes the performanceof each of the database systems 12 and 14 and adjusts their respectiveoperational characteristics in response to the analysis. The analysisincludes determining whether a particular class of queries are processedin accordance with one or more SLGs assigned to that class of queries.

In brief, the CLSM Regulator 10 separates incoming queries into workloadgroups for each database system 12 and 14 in accordance with predefinedprinciples. Each workload group has assigned to it one or morerespective SLGs. Each database system 12 and 14 maintains logs andobtains data to determine whether or not SLGs are being met forparticular workload groups, and makes adjustments to operationalcharacteristics in response. The typical objective is to adjustavailable settings such that the SLGs are met.

The precise nature of how workload groups are defined and settingsadjusted is generally beyond the scope of the present disclosure, andvarious aspects are dealt with in detail in the cross-referencedapplications set forth above. Other embodiments are used with databasesystems that use alternate architectures to analyze their performanceand inherently adjust their respective operational characteristics inresponse to the analysis.

As noted above, in some CLSM-type systems, incoming queries are splitinto workload groups, wherein each workload group has its respectiveSLGs. The DBMS may be responsive to whether or not these goals are metfor selectively switching between predetermined working values definedwithin a rule set or adjusting performance controls.

In this regard, the full set of workload definitions as well as filters,throttles and priority scheduler settings are considered a “rule set”for the system.

For “normal operating procedures”, one set of behaviors defined for arule set can generally manage workloads and system performance well. Forexample, when arrival rates per workload are in anticipated ranges, andall system components are up and functioning, a workload manager's themanagement of CPU, concurrency and workload exceptions can effectivelymanage workload performance. However, external or system-wide events cancause workload performance to stray beyond reasonable levels.

In addition, the business environment can impose restrictions on thesystem's performance. In the present invention, a database administrator(DBA) has the ability to specify different behaviors depending on thecurrent situation. This is done through the definition of atwo-dimensional state matrix of system conditions (SysCons) andoperating environments (OpEnvs).

A sample matrix is illustrated below:

State Matrix Operating System Environments Conditions Interactive BatchGreen Interactive Batch State State Yellow Interactive Batch YellowState State Red Interactive Batch Red State State

A System Condition (SysCon) represents the “condition” or “health” ofthe system, e.g., degraded to the “red” system condition because a nodeis down.

An Operational Environment (OpEnv) represents the “kind of work” thatthe system is being expected to perform, e.g., within the batchoperational environment, because a load job is executing.

The elements of the State Matrix are <SysCon, OpEnv> pairs. Each StateMatrix element references a State. Multiple matrix elements mayreference a common State. Only one State is in effect at any given time,based on the matrix element referenced by the highest severity SysConand the highest precedence OpEnv in effect. Many <SysCon, OpEnv> pairscorrelate to fewer States. Each State has a Working Value Set. A<SysCon, OpEnv> or the State can change as directed by event directivesdefined by the DBA.

In the present example, operational characteristics include performancestatistics, rule sets (e.g., working values) under which a databasesystem 12 or 14 is operating, physical attributes, and so on.

Some particular examples are set out below:

-   -   Memory—the amount of system and subsystem memory currently being        used. It is possible that the system will include some memory        that is shared among all of the subsystems.    -   The number of available access module processor (AMP) worker        tasks (AWTs)—an AMP is a module within a database system 12 or        14 that performs a task, and an AWT is a thread or task within        an AMP for performing the work assigned by a dispatcher. Each        AMP has a predetermined number of AWTs in a pool available for        processing. When a task is assigned to an AMP, one or more AWTs        are assigned to complete the task. When the task is complete,        the AWTs are released back into the pool. As an AMP is assigned        tasks to perform, its available AWTs are reduced. As it        completes tasks, its available AWTs are increased.    -   File SeGment (FSG) Cache—the amount of FSG cache that has been        consumed. The FSG cache is physical memory that buffers data as        it is being sent to or from the data storage facilities.    -   Arrival rates—the rate at which requests are arriving. Arrival        rates are often broken down and used as a resource management        tool on a workload basis.    -   Co-existence—the co-existence of multiple types of processors        and or processor types.    -   Skew—the degree to which data (and therefore processing) is        concentrated in one or more AMPs as compared to the other AMPs.    -   Blocking/locking—the degree to which data access are blocked or        locked because other processes are accessing data.    -   Spool—the degree of consumption of disk space allocated to        temporary storage.    -   Missed SLGs.    -   Node, cpu, memory, disk, channel, network and interconnect        failures.

The CLSM Regulator 10 includes an input 24 for receiving a request 26from a user 28. Although user 28 is illustrated as a person, it will beappreciated that various hardware and software devices also providerequests 26.

Request 26 is typically a database query, such as a tactical query. Inthe present embodiment, database systems 12 and 14 define a dual-activesystem where either database system 12 or 14 is capable of handling arequest 26. Despite this, it will be appreciated that one of thedatabase systems 12 or 14 is often able to handle a request 26 moreefficiently given its operational characteristics. As such, a processor30 is responsive to interface 24 for selecting one of database systems12 or 14, or both database systems 12 and 14, to process a receivedrequest 26.

An output 32 provides the request the selected database system 12 or 14for processing. In FIG. 1, output 32 is shown to be providing requeststo both database systems 12 and 14. This is meant to illustrate theprovision of at least two discrete requests, as well as a singlerequest, being provided to both database systems 12 and 14.

In the present embodiment, output 32 provides request 26 to databasesystems 12 and 14 in accordance with a predetermined queryprioritization protocol, such as that administered by an implementationof a Priority Scheduler Facility (PSF) or a similar component. Monitor20 adjusts this predetermined query prioritization protocol in responseto data 18. For example, in an embodiment where PSF is used, monitor 20adjusts the PSF settings, such a class weights.

Processor 30 categorizes the request into one of a plurality ofpredetermined workload groups. As previously mentioned, each workloadgroup has its respective SLGs. These SLGs relate to response times andthe like, and generally comprise levels of service that are expectedfrom database systems 12 or 14 in the processing of a request 26. Indetermining which database system 12 or 14 should be selected to processa request 26, processor 30 is responsive to operational characteristicsthat indicate the ability of a particular database system 12 or 14 toprocess a request 26 belonging to a particular workload group inaccordance with the SLGs of that workload group. For example, eachdatabase system 12 and 14 is operated under one of a group ofpredetermined system resource consumption rules sets. Processor 30 isinitiated to recognize a particular rule set as being particularlysuited to handling a certain workload mix.

As a simple example, consider two generic exemplary workloadgroups—tactical queries and background queries. Assume that rule set Ais most suitable for handling tactical queries, and rule set B is mostsuitable for handling background queries. For the sake of the example,interface 16 has obtained data indicative of database system 12operating under rule set A, and database system 14 operating under ruleset B. A tactical query is received by interface 24, and recognized as atactical query by processor 30. Processor 30 is then responsive tointerface 24 for selecting database system 12 to process that tacticalquery.

The above example is over simplistic to a degree. In some circumstances,interface 16 obtains other operational characteristics of databasesystem 12 that suggest it is not meeting SLGs for tactical queries. Insuch a case, processor 30 selects database system 14 for the tacticalquery. In practical terms, tactical queries are directed to databasesystem 14 until interface 16 obtains data to which processor 30 isresponsive for altering the procedure.

Monitor 20 is responsive to processor 30 for providing a signal 22identifying these decisions. Using the above example, when processor 30begins to send a stream of tactical queries to database system 14, theworkload mix of database system 14 changes. As such, rule set B is notnecessarily the optimal choice; in the present example, assume that ruleset C is more suitable. In such a case, monitor 20 takes the pro-activestep of sending a signal 22 to database system 14 and, in response,database system 14 adapts for operation under rules set C.

Processor 30 is responsive to whether SLGs for requests 26 are being metacross the domain defined collectively by database systems 12 and 14. Tothis end, monitor 20 adjusts operational characteristics such as OpEnvs,SysCons, system states and/or rule sets for either or both of databasesystems 12 and 14. It will be appreciated that this assists in theprovision of a domain wide approach to workload administration.

It will also be appreciated that, at a high level, the CLSM Regulator 10monitors, on a short-term basis, the execution of requests to detect adeviation from the SLGs and, where a sufficient deviation is detected,the assignment of system resources to particular workload groups acrossthe plurality of database systems 12 and 14 are adjusted to reduce thedeviation.

Referring to FIGS. 2, 3, 4 and 5, embodiments will now be described withreference to a domain 34 comprised of a plurality of multipledual-active database systems 36, wherein each of the dual-activedatabase systems 36 is managed by one or more CLSM Regulators 38 and thedomain 34 is managed by one or more multi-system Virtual Regulators 40.

Managing system resources on the basis of individual systems andrequests does not, in general, satisfactorily manage complex workloadsand SLGs across a domain 34 of database systems 36 in a multi-systemenvironment. To automatically achieve workload goals in a multi-systemenvironment, performance goals must first be defined (administered),then managed (regulated), and finally monitored across the entire domain(set of systems participating in an n-system environment).

CLSM Regulators 38 are used to manage workloads on an individual system36 basis. Under the present embodiment, the Virtual Regulator 40comprises a modified CLSM Regulator 38 implemented to enhance the CLSMarchitecture. That is, by extending the functionality of the CLSMRegulator 38 components, complex workloads are manageable across adomain 34.

The function of the Virtual Regulator 40 is to control and manageexisting CLSM Regulators 38 across all systems 36 in a domain 34. Thenew functionality of the Virtual Regulator 38 extends the existing CLSMgoal oriented workload management infrastructure, which is capable ofmanaging various types of workloads encountered during processing 42.

In one embodiment, the Virtual Regulator 40 includes a “thin” version ofa database system 36, where the “thin” database system 36 means adatabase system 36 executing in an emulation mode, such as described inU.S. Pat. Nos. 6,738,756, 7,155,428, 6,801,903 and 7,089,258. The queryoptimizer function of the “thin” database system 36 allows the VirtualRegulator 40 to classify received queries into “who, what, where”classification criteria, and allows the query director function of the“thin” database system 36 to perform the actual routing of the queriesamong multiple systems 36 in the domain 34. In addition, the use of the“thin” database system 36 in the Virtual Regulator 40 provides ascalable architecture, open application programming interfaces (APIs),external stored procedures (XSPs), user defined functions (UDFs),message queuing, logging capabilities, rules engines, etc.

The Virtual Regulator 40 also includes a set of open APIs, known as“Traffic Cop” APIs, that provide the Virtual Regulator 40 with theability to monitor system 36 states, to obtain system 36 status andconditions, to activate inactive systems 36, to deactivate activesystems 36, to set workload groups, to delay queries (i.e., to controlor throttle throughput), to reject queries (i.e., to filter queries), tosummarize data and statistics, and to create dynamic operating rules.The Traffic Cop APIs are also made available to the CLSM Regulators 38,thereby allowing the CLSM Regulators 38 and Virtual Regulator 40 tocommunicate this information between themselves in a multi-system domain34.

Specifically, the Virtual Regulator 40 performs the following functions:

(a) Regulate (adjust) system 36 conditions (resources, settings, PSFweights, etc.) against workload expectations (SLGs) across the domain34, and to direct query traffic to any of the systems 36 via a set ofpredefined rules.

(b) Monitor and manage system 36 conditions across the domain 34,including adjusting or regulating response time requirements by system36, as well as using the Traffic Cop APIs to handle filter, throttleand/or dynamic allocation of resource weights within systems 36 andpartitions so as to meet SLGs across the domain 34.

(c) Raise an alert to a database administrator for manual handling(e.g., defer or execute query, recommendation, etc.)

(d) Cross-compare workload response time histories (via a query log)with workload SLGs across the domain 34 to determine if query gating(i.e., flow control) through altered Traffic Cop API settings presentsfeasible opportunities for the workload.

(e) Manage and monitor the sub-system CLSM Regulators 38 across thedomain 34 using the Traffic Cop APIs, so as to avoid missing SLGs oncurrently executing workloads, or to allow workloads to execute thequeries while missing SLGs by some predefined or proportional percentagebased on shortage of resources (i.e., based on predefined rules).

(f) Route queries (traffic) to available systems 36.

Although FIG. 2 depicts an implementation using a single VirtualRegulator 40 for the entire domain 34, in some exemplary environments,one or more backup Virtual Regulators 40 are also provided forcircumstances where the primary Virtual Regulator 40 malfunctions or isotherwise unavailable. Such backup Virtual Regulators 40 may be activeor may remain dormant until needed.

Referring to FIG. 3, both the CLSM Regulator 38 and Virtual Regulator 40include an exception monitor 44 for detecting workload exceptions, whichare recorded in a log 46. A system condition monitor 48 is provided todetect system 36 conditions, such as node failures. These collectivelydefine an exception attribute monitor 50.

In practice, both the CLSM Regulator 38 and Virtual Regulator 40 receiverequests, and assign these requests into their respective workloadgroups and priority classes at 52. The assigned requests are then passedthrough a workload query manager 54, also known as a delay manager. Theworkload query manager 54 is responsive to workload rules 56 andexception monitor 44 for either passing a request on or placing it in aqueue until predetermined conditions are met.

If passed, the requests are split into their priority classes 58 forhandling by PSF 60. PSF 60 is responsive to the priority classes 58 forproviding the requests in accordance with predefined principles forprocessing at 42. These principles are updated over time in response tosystem monitor 48 and exception monitor 44. PSF 60 reports observedsystem 36 conditions to monitor 48 and throughput information to monitor44, which are responsive to such information for updating the principlesunder which the PSF 60 operates.

Both the CLSM Regulator 38 and Virtual Regulator 40 use a set ofuser-defined rules 56, or heuristics, to guide a feedback mechanism thatmanages the throughput of a workload for each workload group defined inthe system. In general, Virtual Regulator 40 provides a single view ofmanaging workloads and the associated rules 56 across the domain 34.Meanwhile, CLSM Regulators 38 continue to support workloads in a CLSMenvironment running on each system 36 defined in domain 34.

The Virtual Regulator 40 manages PSF 60 settings and workload groups bycontrolling CLSM Regulators 38 and/or adjusting workload rules 56 inorder to achieve SLGs. It also monitors operational characteristics,such as system 36 conditions, exceptions, system 36 failures, workloadexceptions and the like. Further, it controls the amount of work allowedinto each system 36 to meet SLGs across domain 34.

The Virtual Regulator 40 gathers system 36 information by broadcastingto all CLSM Regulators 38 in domain 34 a request that they report theircurrent status. This will be recognized as the functionality ofinterface 16 in FIG. 1.

In some embodiments, each system 36 may have superordinate andsubordinate systems 36, and so on. An example of this is shown in FIG.4, which illustrates a tree structure. In such embodiments, each CLSMRegulator 38 gathers information related to its own systems 36, as wellas that of its children CLSM Regulators 38, and reports the aggregatedinformation to its parent CLSM Regulator 38 or the Virtual Regulator 40at the highest level of the tree. In some cases, each CLSM Regulator 38waits until it has received information from its children CLSMRegulators 38 before forwarding the aggregated information to its parentCLSM Regulator 38 or the Virtual Regulator 40. In that way, the system36 information is compiled from the bottom of the tree to the top. Whenthe Virtual Regulator 40 compiles its information with that which isreported by all of the CLSM Regulators 38, it will have completeinformation for domain 34. The Virtual Regulator 40 analyzes theaggregated information to apply rules and make adjustments.

In the example shown in FIG. 4, the tree is a binary tree. It will beunderstood that other types of trees will fall within the scope of thisbroad invention. Further, while the tree in FIG. 4 is symmetrical,symmetry is not a limitation.

In another example system, each CLSM Regulator 38 communicates itssystem 36 information directly to the Virtual Regulator 40. The VirtualRegulator 40 compiles the information, adds domain 34 or additionalsystem 36 level information, to the extent there is any, and makes itsadjustments based on the resulting set of information.

Each CLSM Regulator 38 monitors and controls, in a closed loop fashion,workload group performance information for a single system 36 ordual-active system 36. For example, this may require performanceinformation received from a dispatcher processor, wherein theperformance information is compared to SLGs 62. In the example ofthroughput information, the level of desired throughput defined in SLGs62 is compared to the actual level of throughput occurring for aparticular workload. The Virtual Regulator 40 then adjusts resourceallocation weights to better meet the workload rules.

Referring to FIG. 5, the Virtual Regulator 40 receives informationconcerning the states, events and conditions of the systems 36 from theCLSM Regulators 38, and compares these states, events and conditions tothe SLGs 62. In response, the Virtual Regulator 40 adjusts theoperational characteristics of the various systems 36 through a set of“Traffic Cop” Open APIs to better address the states, events andconditions of the systems 36 throughout the domain 34.

To manage workloads among dynamic domain 34 wide situations, the VirtualRegulator 40 classifies the various states, events and conditions intoat least three general detection categories and specifies what automatedactions should occur in response thereto, as set forth below:

1. Detection category: system, device or application state.

-   -   a. This category detects the state of a system 36, device or        application (e.g., down, recovered, degraded, etc.), as        communicated through a monitored message queue.

2. Detection category: system, device or application event.

-   -   a. One event detected is an operating window time boundary.    -   b. Another event detected is when an application, device or        system is started or ended (as communicated through a monitored        message queue). For example, in order for a request to the        database system 36 to enter, initiate or continue under a given        workload group, it can be additionally pre-qualified to satisfy        one or more event-based “when” conditions.    -   An example of the types of events supported includes “daily load        against table X is about to start.” This event triggers a phased        set of actions: (a) begin acquisition phase of multi-load to        table X, (b) promote the priority of all queries that involve        table X, (c) at the same time, restrict the ability for new        queries involving table X from starting until after the data        load is completed (do this through delay, scheduling or        disallowing the query upon request), (d) after y minutes or upon        completion of the acquisition phase (which ever comes later),        previously promoted queries that are still running are aborted        (“times up!”), (e) begin the apply phase of the data load,        and (f) upon completion of data load, raise restrictions on        queries involving table X, and allow scheduled and delayed        queries to resume.    -   Another example is to allow the user to define and automate        workload group changes based on an event (rather than resource        or time changes per the PSF 60). For example, customers may like        to have workload groups change when the daily load application        is submitted to the system 36, or based on a business calendar        that treats weekends and holidays differently from weekdays, or        that treats normal processing differently from quarterly or        month-end processing.    -   What is different about this type of initiation is that it may        mean one query or event can have an impact on other queries        already in execution or that will soon be requested.    -   c. Another event detected is sustained CPU and I/O for some        qualifying time, e.g., either high or low. For example, the        category may initiate background tasks when system 36        utilization is low, and eliminate them when system 36        utilization is high.    -   d. User-definable event.    -   e. Replication service.    -   f. Other events.

3. Detection category: system, device or application condition. Theseconditions are detected by an individual request or workload group beingimpacted (e.g., average response time greater than the SLG for somequalifying interval) by a condition and can be implemented throughexisting exception monitoring rather than more difficult domain 34 widedetection. Preferably, there are “symptom” and “cause” conditions:

-   -   a. Symptom: response time greater than x.    -   b. Symptom: block time greater than x.    -   c. Cause: low or no AWT availability for some time period.    -   d. Cause: arrival rate greater than expected (e.g., a surge).    -   e. Cause: response time for all workload groups exceeded.    -   f. Cause: response time for one workload group exceeded.

4. Automated actions. Upon detection of any of the above states, events,or conditions, one or more automated actions can be triggered by theVirtual Regulator 40 or CLSM Regulator 38. Automated actions may include(but are not limited to) the following:

-   -   a. Alerting an operator.    -   b. Notifying one or more systems 36.    -   c. Logging the states, events and conditions.    -   d. Changing the rules for one or more workload groups.    -   e. Re-routing one or more workload groups to other systems.    -   f. Aborting one or more workload groups.

Alternatively, there may be some other action taken in order toautomatically resolve the detected category. Moreover, many othercategories of detections and automated actions can be implemented.

Generally speaking, CLSM Regulators 38 provide real-time closed-loopsystem management over resources within the systems 36, with the loophaving a fairly narrow bandwidth, typically on the order ofmilliseconds, seconds, or minutes. The Virtual Regulator 40 providesreal-time closed-loop system management over resources within the domain34, with the loop having a much larger bandwidth, typically on the orderof minutes, hours, or days.

Further, while CLSM Regulators 38 controls resources within the systems36, and the Virtual Regulator 40 controls resources across the domain34, in many cases, system 36 resources and domain 34 resources are thesame. The Virtual Regulator 40 has a higher level view of resourceswithin the domain 34, because it is aware of the state of resources ofall systems 36, while each CLSM Regulator 38 is generally only aware ofthe state of resources within its own systems 36.

There are a number of techniques by which Virtual Regulator 40implements its adjustments to the allocation of system 36 resources. Forexample, and as illustrated in FIG. 2, the Virtual Regulator 40communicates adjustments directly to CLSM Regulators 38, and the CLSMRegulators 38 then apply the relevant rule adjustments. Alternatively,the Virtual Regulator 40 communicates adjustments to the CLSM Regulators38 by passing them down a tree, such as that in FIG. 4. In either case,the CLSM Regulators 38 incorporate adjustments ordered by the VirtualRegulator 40 in the various systems 36.

Given that the Virtual Regulator 40 has access to the state, event andcondition information from all CLSM Regulators 38, it can makeadjustments that are mindful of meeting SLGs for various workloadgroups. It is capable of, for example, adjusting the resources allocatedto a particular workload group on a domain 34 basis, to make sure thatthe SLGs for that workload group are met. It is further able to identifybottlenecks in performance and allocate resources to alleviate thebottleneck. Also, it selectively deprives resources from a workloadgroup that is idling resources. In general, the Virtual Regulator 40provides a domain 34 view of workload administration, while the CLSMRegulators 38 provide a system 36 view of workload administration.

Thus, it will be appreciated that the illustrated Virtual Regulator 40is capable of monitoring the performance and operational characteristicsof a plurality of systems 36 across a domain 34. From this, it providesa domain 34 based approach to resource and performance management.

CONCLUSION

This concludes the description of the preferred embodiment of theinvention. The following describe some alternative embodiments foraccomplishing the same invention.

The invention has been primarily developed for monitoring and adjustingthe operational characteristics of a plurality of systems within adomain. However, it will be appreciated that the invention is in nosense limited to that application. For example, the invention isgenerally applicable to a wide variety of environments where suchfunctionality has value.

The foregoing description of the preferred embodiment of the inventionhas been presented for the purposes of illustration and description. Itis not intended to be exhaustive or to limit the invention to theprecise form disclosed. Many modifications and variations are possiblein light of the above teaching. It is intended that the scope of theinvention be limited not by this detailed description, but rather by theclaims appended hereto.

1. A system for managing a plurality of systems, comprising: (a) adomain comprised of a plurality of systems, wherein each of the systemsare managed by one or more closed-loop system management (CLSM)regulators; and (b) a virtual regulator for managing operationalcharacteristics of the domain and the plurality of systems, wherein thevirtual regulator communicates with the CLSM regulators to monitor thesystems' states, events and conditions within the domain and to adjustthe systems' operational characteristics in response to the systems'states, events and conditions.
 2. The system of claim 1, wherein thevirtual regulator communicates with the CLSM regulators using a trafficcop application programming interface (API).
 3. The system of claim 1,wherein the virtual regulator receives information concerning thesystems' states, events and conditions from the CLSM regulators.
 4. Thesystem of claim 3, wherein the systems' states include system, device orapplication states.
 5. The system of claim 3, wherein the systems'events include system, device or application events.
 6. The system ofclaim 3, wherein the systems' conditions include system, device orapplication conditions.
 7. The system of claim 3, wherein the systems'conditions include symptom and cause conditions.
 8. The system of claim3, wherein the virtual regulator sends information concerning thesystems' resources to the CLSM regulators in response to the receivedinformation concerning the systems' states, events and conditions. 9.The system of claim 3, wherein the virtual regulator performs one ormore automated actions upon detecting the systems' states, events andconditions.
 10. The system of claim 9, wherein the automated actionsincludes alerting an operator, notifying one or more systems, loggingthe states, events and conditions, changing rules for one or moreworkloads, re-routing one or more workloads, or aborting one or moreworkloads.
 11. The system of claim 1, wherein the CLSM regulatorscontrol resources within the system and the virtual regulator controlsresources across the domain.
 12. The system of claim 11, wherein thevirtual regulator communicates adjustments to the CLSM regulators, andthe CLSM regulators apply the adjustments to the systems.
 13. A methodof managing a plurality of database systems, comprising: (a) managingeach of a plurality of systems in a domain using one or more closed-loopsystem management (CLSM) regulators; and (b) managing operationalcharacteristics of the domain and the plurality of systems using avirtual regulator, wherein the virtual regulator communicates with theCLSM regulators to monitor the systems' states, events and conditionswithin the domain and to adjust the systems' operational characteristicsin response to the systems' states, events and conditions.
 14. Themethod of claim 13, wherein the virtual regulator communicates with theCLSM regulators using a traffic cop application programming interface(API).
 15. The method of claim 13, wherein the virtual regulatorreceives information concerning the systems' states, events andconditions from the CLSM regulators.
 16. The method of claim 15, whereinthe systems' states include system, device or application states. 17.The method of claim 15, wherein the systems' events include system,device or application events.
 18. The method of claim 15, wherein thesystems' conditions include system, device or application conditions.19. The method of claim 15, wherein the systems' conditions includesymptom and cause conditions.
 20. The method of claim 15, wherein thevirtual regulator sends information concerning the systems' resources tothe CLSM regulators in response to the received information concerningthe systems' states, events and conditions.
 21. The method of claim 15,wherein the virtual regulator performs one or more automated actionsupon detecting the systems' states, events and conditions.
 22. Themethod of claim 21, wherein the automated actions includes alerting anoperator, notifying one or more systems, logging the states, events andconditions, changing rules for one or more workloads, re-routing one ormore workloads, or aborting one or more workloads.
 23. The method ofclaim 13, wherein the CLSM regulators control resources within thesystem and the virtual regulator controls resources across the domain.24. The method of claim 23, wherein the virtual regulator communicatesadjustments to the CLSM regulators, and the CLSM regulators apply theadjustments to the systems.